<!--#if expr="$FAQMASTER" -->
 <!--#set var="STANDALONE" value="" -->
 <!--#set var="INCLUDED" value="YES" -->
 <!--#if expr="$QUERY_STRING = TOC" -->
  <!--#set var="TOC" value="YES" -->
  <!--#set var="CONTENT" value="" -->
 <!--#else -->
  <!--#set var="TOC" value="" -->
  <!--#set var="CONTENT" value="YES" -->
 <!--#endif -->
<!--#else -->
 <!--#set var="STANDALONE" value="YES" -->
 <!--#set var="INCLUDED" value="" -->
 <!--#set var="TOC" value="" -->
 <!--#set var="CONTENT" value="" -->
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Apache Server Frequently Asked Questions</TITLE>
 </HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  TEXT="#000000"
  LINK="#0000FF"
  VLINK="#000080"
  ALINK="#FF0000"
 >
  <!--#include virtual="header.html" -->
  <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
  <P>
  $Revision: 1.4 $ ($Date: 1999/07/04 16:33:00 $)
  </P>
  <P>
  The latest version of this FAQ is always available from the main
  Apache web site, at
  &lt;<A
       HREF="http://www.apache.org/docs/misc/FAQ.html"
       REL="Help"
      ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
  </P>
<!-- Notes about changes:                                           -->
<!--  - If adding a relative link to another part of the            -->
<!--    documentation, *do* include the ".html" portion.  There's a -->
<!--    good chance that the user will be reading the documentation -->
<!--    on his own system, which may not be configured for          -->
<!--    multiviews.                                                 -->
<!--  - When adding items, make sure they're put in the right place -->
<!--    - verify that the numbering matches up.                     -->
<!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
<!--    correctly in a reliable way when this is converted to text  -->
<!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
<!--    blocks inside a <P></P> instead.  This is necessary to get  -->
<!--    the horizontal and vertical indenting right.                -->
<!--  - Don't forget to include an HR tag after the last /P tag     -->
<!--    but before the /LI in an item.                              -->
  <P>
  If you are reading a text-only version of this FAQ, you may find numbers
  enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
  reference URLs to be found at the end of the document.  These references
  do not appear, and are not needed, for the hypertext version.
  </P>
  <H2>The Questions</H2>
<OL TYPE="A">
<!--#endif -->
<!--#if expr="$TOC || $STANDALONE" -->
 <LI VALUE="5"><STRONG>Configuration Questions</STRONG>
  <OL>
   <LI><A HREF="#fdlim">Why can't I run more than &lt;<EM>n</EM>&gt;
        virtual hosts?</A>
   </LI>
   <LI><A HREF="#freebsd-setsize">Can I increase <SAMP>FD_SETSIZE</SAMP>
        on FreeBSD?</A>
   </LI>
   <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
        401</CODE> work?</A>
   </LI>
   <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
   </LI>
   <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
        <SAMP>mod_cookies</SAMP>?</A>
   </LI>
   <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
        when I request an URL from an Apache server?</A>
   </LI>
   <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
        browser can play it?</A>
   </LI>
   <LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A>
   </LI>
   <LI><A HREF="#set-servername">Why does accessing directories only work
        when I include the trailing &quot;/&quot;
        (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>) but
        not when I omit it
        (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</A>
   </LI>
   <LI><A HREF="#no-info-directives">Why doesn't mod_info list any
        directives?</A>
   </LI>
   <LI><A HREF="#namevhost">I upgraded to Apache 1.3 and now my
        virtual hosts don't work!</A>
   </LI>
   <LI><A HREF="#redhat-htm">I'm using RedHat Linux and my .htm files are
        showing up as HTML source rather than being formatted!</A>
   </LI>
   <LI><A HREF="#htaccess-work">My <CODE>.htaccess</CODE> files are being
	ignored.</A>
   </LI>
   <LI><A HREF="#forbidden">Why do I get a 
        &quot;<SAMP>Forbidden</SAMP>&quot; message whenever I try to 
        access a particular directory?</A>
  </OL>
 </LI>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
</OL>

<HR>

  <H2>The Answers</H2>
<!--#endif -->
<!--#if expr="! $TOC" -->

  <H3>E. Configuration Questions</H3>
<OL>

 <LI><A NAME="fdlim">
      <STRONG>Why can't I run more than &lt;<EM>n</EM>&gt;
      virtual hosts?</STRONG>
     </A>
  <P>
  You are probably running into resource limitations in your
  operating system.  The most common limitation is the
  <EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>,
  which is almost always the cause of problems seen when adding
  virtual hosts.  Apache often does not give an intuitive error
  message because it is normally some library routine (such as
  <CODE>gethostbyname()</CODE>) which needs file descriptors and
  doesn't complain intelligibly when it can't get them.
  </P>
  <P>
  Each log file requires a file descriptor, which means that if you are
  using separate access and error logs for each virtual host, each
  virtual host needs two file descriptors.  Each
  <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
  directive also needs a file descriptor.
  </P>
  <P>
  Typical values for &lt;<EM>n</EM>&gt; that we've seen are in
  the neighborhood of 128 or 250.  When the server bumps into the file
  descriptor limit, it may dump core with a SIGSEGV, it might just
  hang, or it may limp along and you'll see (possibly meaningful) errors
  in the error log.  One common problem that occurs when you run into
  a file descriptor limit is that CGI scripts stop being executed
  properly.
  </P>
  <P>
  As to what you can do about this:
  </P>
  <OL>
   <LI>Reduce the number of
    <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
    directives.  If there are no other servers running on the machine
    on the same port then you normally don't
    need any Listen directives at all.  By default Apache listens to
    all addresses on port 80.
   </LI>
   <LI>Reduce the number of log files.  You can use
    <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
    to log all requests to a single log file while including the name
    of the virtual host in the log file.  You can then write a
    script to split the logfile into separate files later if
    necessary.  Such a script is provided with the Apache 1.3 distribution
    in the <SAMP>src/support/split-logfile</SAMP> file.
   </LI>
   <LI>Increase the number of file descriptors available to the server
    (see your system's documentation on the <CODE>limit</CODE> or
    <CODE>ulimit</CODE> commands).  For some systems, information on
    how to do this is available in the
    <A HREF="perf.html">performance hints</A> page.  There is a specific
    note for <A HREF="#freebsd-setsize">FreeBSD</A> below.
    <P>
    For Windows 95, try modifying your <SAMP>C:\CONFIG.SYS</SAMP> file to
    include a line like
    </P>
    <DL>
     <DD><CODE>FILES=300</CODE>
     </DD>
    </DL>
    <P>
    Remember that you'll need to reboot your Windows 95 system in order
    for the new value to take effect.
    </P>
   </LI>
   <LI>&quot;Don't do that&quot; - try to run with fewer virtual hosts
   </LI>
   <LI>Spread your operation across multiple server processes (using
    <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
    for example, but see the first point) and/or ports.
   </LI>
  </OL>
  <P>
  Since this is an operating-system limitation, there's not much else
  available in the way of solutions.
  </P>
  <P>
  As of 1.2.1 we have made attempts to work around various limitations
  involving running with many descriptors.
  <A HREF="descriptors.html">More information is available.</A>
  </P>
  <HR>
 </LI>

 <LI><A NAME="freebsd-setsize">
      <STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG>
     </A>
  <P>
  On versions of FreeBSD before 3.0, the <SAMP>FD_SETSIZE</SAMP> define 
  defaults to 256.  This means that you will have trouble usefully using
  more than 256 file descriptors in Apache.  This can be increased, but
  doing so can be tricky.
  </P>
  <P>
  If you are using a version prior to 2.2, you need to recompile your
  kernel with a larger <SAMP>FD_SETSIZE</SAMP>.  This can be done by adding a 
  line such as:
  </P>
  <DL>
   <DD><CODE>options FD_SETSIZE <EM>nnn</EM></CODE>
   </DD>
  </DL>
  <P>
  to your kernel config file.  Starting at version 2.2, this is no
  longer necessary.
  </P>
  <P>
  If you are using a version of 2.1-stable from after 1997/03/10 or
  2.2 or 3.0-current from before 1997/06/28, there is a limit in
  the resolver library that prevents it from using more file descriptors
  than what <SAMP>FD_SETSIZE</SAMP> is set to when libc is compiled.  To
  increase this, you have to recompile libc with a higher
  <SAMP>FD_SETSIZE</SAMP>.
  </P>
  <P>
  In FreeBSD 3.0, the default <SAMP>FD_SETSIZE</SAMP> has been increased to
  1024 and the above limitation in the resolver library
  has been removed.
  </P>
  <P>
  After you deal with the appropriate changes above, you can increase 
  the setting of <SAMP>FD_SETSIZE</SAMP> at Apache compilation time 
  by adding &quot;<SAMP>-DFD_SETSIZE=<EM>nnn</EM></SAMP>&quot; to the
  <SAMP>EXTRA_CFLAGS</SAMP> line in your <SAMP>Configuration</SAMP>
  file.
  </P>
  <HR>
 </LI>

 <LI><A NAME="errordoc401">
      <STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG>
     </A>
  <P>
  You need to use it with a URL in the form
  &quot;<SAMP>/foo/bar</SAMP>&quot; and not one with a method and
  hostname such as &quot;<SAMP>http://host/foo/bar</SAMP>&quot;.  See the
  <A HREF="../mod/core.html#errordocument"><SAMP>ErrorDocument</SAMP></A>
  documentation for details.  This was incorrectly documented in the past.
  </P>
  <HR>
 </LI>

 <LI><A NAME="cookies1">
      <STRONG>Why does Apache send a cookie on every response?</STRONG>
     </A>
  <P>
  Apache does <EM>not</EM> automatically send a cookie on every
  response, unless you have re-compiled it with the
  <A HREF="../mod/mod_usertrack.html"><SAMP>mod_usertrack</SAMP></A>
  module, and specifically enabled it with the
  <A HREF="../mod/mod_usertrack.html#cookietracking"
  ><SAMP>CookieTracking</SAMP></A>
  directive.
  This module has been in Apache since version 1.2.
  This module may help track users, and uses cookies to do this. If
  you are not using the data generated by <SAMP>mod_usertrack</SAMP>, do
  not compile it into Apache. 
  </P>
  <HR>
 </LI>

 <LI><A NAME="cookies2">
      <STRONG>Why don't my cookies work, I even compiled in
      <SAMP>mod_cookies</SAMP>?
      </STRONG>
     </A>
  <P>
  Firstly, you do <EM>not</EM> need to compile in
  <SAMP>mod_cookies</SAMP> in order for your scripts to work (see the
  <A HREF="#cookies1">previous question</A>
  for more about <SAMP>mod_cookies</SAMP>). Apache passes on your
  <SAMP>Set-Cookie</SAMP> header fine, with or without this module. If
  cookies do not work it will be because your script does not work
  properly or your browser does not use cookies or is not set-up to
  accept them.
  </P>
  <HR>
 </LI>

 <LI><A NAME="jdk1-and-http1.1">
      <STRONG>Why do my Java app[let]s give me plain text when I request
      an URL from an Apache server?</STRONG>
     </A>
  <P>
  As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol
  version 1.1) server.  This fact is reflected in the protocol version
  that's included in the response headers sent to a client when
  processing a request.  Unfortunately, low-level Web access classes
  included in the Java Development Kit (JDK) version 1.0.2 expect to see
  the version string &quot;HTTP/1.0&quot; and do not correctly interpret
  the &quot;HTTP/1.1&quot; value Apache is sending (this part of the
  response is a declaration of what the server can do rather than a
  declaration of the dialect of the response).  The result
  is that the JDK methods do not correctly parse the headers, and
  include them with the document content by mistake.
  </P>
  <P>
  This is definitely a bug in the JDK 1.0.2 foundation classes from Sun,
  and it has been fixed in version 1.1.  However, the classes in
  question are part of the virtual machine environment, which means
  they're part of the Web browser (if Java-enabled) or the Java
  environment on the client system - so even if you develop
  <EM>your</EM> classes with a recent JDK, the eventual users might
  encounter the problem.
  The classes involved are replaceable by vendors implementing the
  Java virtual machine environment, and so even those that are based
  upon the 1.0.2 version may not have this problem.
  </P>
  <P>
  In the meantime, a workaround is to tell
  Apache to &quot;fake&quot; an HTTP/1.0 response to requests that come
  from the JDK methods; this can be done by including a line such as the
  following in your server configuration files:
  </P>
  <P>
  <DL>
   <DD><CODE>BrowserMatch Java1.0 force-response-1.0
    <BR>
    BrowserMatch JDK/1.0 force-response-1.0</CODE>
   </DD>
  </DL>
  <P></P>
  <P>
  More information about this issue can be found in the
  <A HREF="http://www.apache.org/info/jdk-102.html"
  ><CITE>Java and HTTP/1.1</CITE></A>
  page at the Apache web site.
  </P>
  <HR>
 </LI>

 <LI><A NAME="midi">
      <STRONG>How do I get Apache to send a MIDI file so the browser can
      play it?</STRONG>
     </A>
  <P>
  Even though the registered MIME type for MIDI files is
  <SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it
  as such; instead, they look for <SAMP>audio/x-midi</SAMP>.  There are
  two things you can do to address this:
  </P>
  <OL>
   <LI>Configure your browser to treat documents of type
    <SAMP>audio/midi</SAMP> correctly.  This is the type that Apache
    sends by default.  This may not be workable, however, if you have
    many client installations to change, or if some or many of the
    clients are not under your control.
   </LI>
   <LI>Instruct Apache to send a different <SAMP>Content-type</SAMP>
    header for these files by adding the following line to your server's
    configuration files:
    <P>
    <DL>
     <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
     </DD>
    </DL>
    <P></P>
    <P>
    Note that this may break browsers that <EM>do</EM> recognize the
    <SAMP>audio/midi</SAMP> MIME type unless they're prepared to also
    handle <SAMP>audio/x-midi</SAMP> the same way.
    </P>
   </LI>
  </OL>
  <HR>
 </LI>

 <LI><A NAME="addlog">
      <STRONG>How do I add browsers and referrers to my logs?</STRONG>
     </A>
  <P>
  Apache provides a couple of different ways of doing this.  The
  recommended method is to compile the
  <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
  module into your configuration and use the
  <A HREF="../mod/mod_log_config.html#customlog"><SAMP>CustomLog</SAMP></A>
  directive.
  </P>
  <P>
  You can either log the additional information in files other than your
  normal transfer log, or you can add them to the records already being
  written.  For example:
  </P>
  <P>
  <CODE>
   CustomLog&nbsp;logs/access_log&nbsp;"%h&nbsp;%l&nbsp;%u&nbsp;%t&nbsp;\"%r\"&nbsp;%s&nbsp;%b&nbsp;\"%{Referer}i\"&nbsp;\"%{User-Agent}i\""
  </CODE>
  </P>
  <P>
  This will add the values of the <SAMP>User-agent:</SAMP> and
  <SAMP>Referer:</SAMP> headers, which indicate the client and the
  referring page, respectively, to the end of each line in the access
  log.
  </P>
  <P>
  You may want to check out the <CITE>Apache Week</CITE> article
  entitled:
  &quot;<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help"
        ><CITE>Gathering Visitor Information: Customizing Your
         Logfiles</CITE></A>&quot;.
  </P>
  <HR>
 </LI>

 <LI><A NAME="set-servername">
      <STRONG>Why does accessing directories only work when I include
      the trailing &quot;/&quot;
      (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>)
      but not when I omit it
      (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG>
     </A>
  <P>
  When you access a directory without a trailing &quot;/&quot;, Apache needs
  to send what is called a redirect to the client to tell it to
  add the trailing slash.  If it did not do so, relative URLs would
  not work properly.  When it sends the redirect, it needs to know
  the name of the server so that it can include it in the redirect.
  There are two ways for Apache to find this out; either it can guess,
  or you can tell it.  If your DNS is configured correctly, it can
  normally guess without any problems.  If it is not, however, then
  you need to tell it.
  </P>
  <P>
  Add a <A HREF="../mod/core.html#servername">ServerName</A> directive
  to the config file to tell it what the domain name of the server is.
  </P>
  <HR>
 </LI>

 <LI><A NAME="no-info-directives">
      <STRONG>Why doesn't mod_info list any directives?</STRONG>
     </A>
  <P>
  The <A HREF="../mod/mod_info.html"><SAMP>mod_info</SAMP></A>
  module allows you to use a Web browser to see how your server is
  configured.  Among the information it displays is the list modules and
  their configuration directives.  The &quot;current&quot; values for
  the directives are not necessarily those of the running server; they
  are extracted from the configuration files themselves at the time of
  the request.  If the files have been changed since the server was last
  reloaded, the display will will not match the values actively in use.
  If the files and the path to the files are not readable by the user as
  which the server is running (see the
  <A HREF="../mod/core.html#user"><SAMP>User</SAMP></A>
  directive), then <SAMP>mod_info</SAMP> cannot read them in order to
  list their values.  An entry <EM>will</EM> be made in the error log in
  this event, however.
  </P>
  <HR>
 </LI>

 <LI><A NAME="namevhost">
      <STRONG>I upgraded to Apache 1.3 and now my virtual hosts don't
      work!</STRONG>
     </A>
  <P>
  In versions of Apache prior to 1.3b2, there was a lot of confusion
  regarding address-based virtual hosts and (HTTP/1.1) name-based
  virtual hosts, and the rules concerning how the server processed
  <SAMP>&lt;VirtualHost&gt;</SAMP> definitions were very complex and not
  well documented.
  </P>
  <P>
  Apache 1.3b2 introduced a new directive,
  <A HREF="http://www.apache.org/docs/mod/core.html#namevirtualhost"
  ><SAMP>NameVirtualHost</SAMP></A>,
  which simplifies the rules quite a bit.  However, changing the rules
  like this means that your existing name-based
  <SAMP>&lt;VirtualHost&gt;</SAMP> containers probably won't work
  correctly immediately following the upgrade.
  </P>
  <P>
  To correct this problem, add the following line to the beginning of
  your server configuration file, before defining any virtual hosts:
  </P>
  <DL>
   <DD><CODE>NameVirtualHost <EM>n.n.n.n</EM></CODE>
   </DD>
  </DL>
  <P>
  Replace the &quot;<SAMP>n.n.n.n</SAMP>&quot; with the IP address to
  which the name-based virtual host names resolve; if you have multiple
  name-based hosts on multiple addresses, repeat the directive for each
  address.
  </P>
  <P>
  Make sure that your name-based <SAMP>&lt;VirtualHost&gt;</SAMP> blocks
  contain <SAMP>ServerName</SAMP> and possibly <SAMP>ServerAlias</SAMP>
  directives so Apache can be sure to tell them apart correctly.
  </P>
  <P>
  Please see the
  <A HREF="http://www.apache.org/docs/vhosts/">Apache
  Virtual Host documentation</A> for further details about configuration.
  </P>
  <HR>
 </LI>

 <LI><A NAME="redhat-htm">
      <STRONG>I'm using RedHat Linux and my .htm files are showing
      up as HTML source rather than being formatted!</STRONG>
     </A>

  <P>
  RedHat messed up and forgot to put a content type for <CODE>.htm</CODE>
  files into <CODE>/etc/mime.types</CODE>.  Edit <CODE>/etc/mime.types</CODE>,
  find the line containing <CODE>html</CODE> and add <CODE>htm</CODE> to it.
  Then restart your httpd server:
  </P>
  <DL>
   <DD><CODE>kill -HUP `cat /var/run/httpd.pid`</CODE>
   </DD>
  </DL>
  <P>
  Then <STRONG>clear your browsers' caches</STRONG>.  (Many browsers won't
  re-examine the content type after they've reloaded a page.)
  </P>
  <HR>
 </LI>

 <LI><A NAME="htaccess-work">
       <STRONG>My <CODE>.htaccess</CODE> files are being ignored.</STRONG></A>
   <P>
   This is almost always due to your <A HREF="../mod/core.html#allowoverride">
   AllowOverride</A> directive being set incorrectly for the directory in 
   question.  If it is set to <CODE>None</CODE> then .htaccess files will 
   not even be looked for.  If you do have one that is set, then be certain 
   it covers the directory you are trying to use the .htaccess file in.  
   This is normally accomplished by ensuring it is inside the proper 
   <A HREF="../mod/core.html#directory">Directory</A> container.
   </P>
   <HR>
 </LI>
 <LI><A NAME="forbidden">
       <STRONG>Why do I get a &quot;<SAMP>Forbidden</SAMP>&quot; message 
       whenever I try to access a particular directory?</STRONG></A>
   <P>
   This message is generally caused because either
   </P>
   <UL>
    <LI>The underlying file system permissions do not allow the
     User/Group under which Apache is running to access the necessary
     files; or
    <LI>The Apache configuration has some access restrictions in 
     place which forbid access to the files.
   </UL>
   <P>
   You can determine which case applies to your situation by checking the
   error log.
   </P>
   <P>
   In the case where file system permission are at fault, remember
   that not only must the directory and files in question be readable,
   but also all parent directories must be at least searchable by the
   web server in order for the content to be accessible.
   </P>
   <HR>
  </LI>
</OL>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
  <!-- Don't forget to add HR tags at the end of each list item.. -->

<!--#include virtual="footer.html" -->
</BODY>
</HTML>
<!--#endif -->
